@bosonbaas, I think this is a good start. I noted some stuff that can be simplified. And we need some tests before this is ready to merge.

Thanks for the comments! It might be useful to wait on pulling this request until we transfer Catlab.Experiments over to it's own dedicated folder ( #144 ) so that this can be placed into that structure.

Very cool. Dagger is new to me, although I once used dask, which looks similar.

Thanks for getting this started, Andrew. I agree that resolving #144 first makes sense.

Currently the only tests I have are comparing the results of expressions evaluated as LinearMaps and as MatrixThunks in an attempt to show equivalence between the two instances. What other tests would be good to have in here?
I'll hold off on asking about the structure of the tests directory here, as I'll put that in #144 for discussion.

Here are the notes from our conversation today, I think we might want to have both the OpenDAG approach you implemented here and a "CT-native" approach like the following Thunk implementation.

AbstractThunk

struct ThunkDom
  types::Vector{DataType}
end
  
struct GeneratorThunk <: AbstractThunk
  dom
  codom
  t::Thunk
end

CompositeThunk <: AbstractThunk
  fs::Vector{AbstractThunk}
end
  
ProductThunk <: AbstractThunk
  fs::Vector{AbstractThunk}
end
  
CopyThunk <: AbstractThunk
  x::ThunkDom
end

BraidThunk <: AbstractThunk
  x::ThunkDom
  y::ThunkDom
end

# copy(X::Ob) → (x)↦CopyThunk(x,y)
# braid(X::Ob, Y::Ob) → (x,y)↦BraidThunk(x,y)

# f⊗g⋅h⋅Δ(x)... ↦ CompositeThunk(ProductThunk(f,g), h, CopyThunk(x))

I haven't looked at this carefully yet, but is the comment I made in #157 relevant here as well?

Yes it is.

@jpfairbanks and @bosonbaas, what are your plans for this experiment? Looks like a solid amount of work has gone into it. One possibility is to just merge it into the experiments basically as is. For that, we would just need to make sure that all the tests still pass and update the experiments GitHub CI action to run the tests (otherwise, bit rot is inevitable).

I think we would want to update it to use something like oapply(d::DWD, args::Vector{Thunk})::Thunk then you would get that Dagger Thunks are an operad algebra for DWDs.

I've made an evaluate function in Algebraic Relations PR 17 which implements the conversion from DWD to Thunk and then evaluates that Thunk.
Would this make sense as something to put in the experiments folder (after being converted to simply an oapply for Thunks)?

I think it makes sense to pull the workflow parts of algebraic relations out into a new package and put this in that package as a DAG construction tool. Algebraic relations could still have the code that generated a schema from a Petri net presentation of an SMC, but the creation and execution of Workflows would go in the new package. Then when you use both Workflows and Relations, you would get checkpointing into SQL for free.

Closing this PR, as it will be better suited to new LinAlg package if we ever pick it up again.